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Introduction 


The Peer-to-Peer Streaming Protocol (PPSP) is composed of two 
protocols: the Tracker Protocol (defined in this document) and the 
Peer Protocol (defined in [RFC7574]). [RFC6972] specifies that the 
Tracker Protocol should standardize the messages between PPSP peers 
and PPSP trackers and also defines the requirements. 


The Peer-to-Peer Streaming Tracker Protocol (PPSTP) provides 
communication between trackers and peers by which peers send meta 
information to trackers, report streaming status, and obtain peer 
lists from trackers. 


The PPSP architecture requires PPSP peers to be able to communicate 
with a tracker in order to participate in a particular streaming 
content swarm. This centralized tracker service is used by PPSP 
peers for acquisition of peer lists. 


The signaling and the media data transfer between PPSP peers is not 
in the scope of this specification. 


This document introduces a base Peer-to-Peer Streaming Tracker 
Protocol (PPSTP) that satisfies the requirements in [RFC6972]. 


1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


absolute time: Expressed as ISO 8601 timestamps, using zero UTC 
offset. Fractions of a second may be indicated, for example, 
December 25, 2010 at 14h56 and 20.25 seconds in basic format is 
20101225T145620.25Z and in extended format is 
2010-12-25T14:56:20.252. 


chunk: An uniformly atomic subset of the resource that constitutes 
the basic unit of data organized in P2P streaming for storage, 
scheduling, advertisement, and exchange among peers. 


chunk ID: A unique resource identifier for a chunk. The identifier 
type depends on the addressing scheme used, i.e., an integer, an 
HTTP-URL, and possibly a byte-range. The identifier type is 
described in the Media Presentation Description (MPD). 


LEECH: The peers in a swarm that download content from other peers as 
well as contribute downloaded content with others. A LEECH should 
join the swarm with uncompleted media content. 
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MPD (Media Presentation Description): Formalized description for a 
media presentation, i.e., describes the structure of the media, 
namely, the representations, the codecs used, the chunks, and the 
corresponding addressing scheme. 


peer: A participant in a P2P streaming system that not only receives 
streaming content, but also caches and streams streaming content 
to other participants. 


peer ID: The identifier of a peer such that other peers, or the 
Tracker, can refer to the peer using its ID. The peer ID is 
mandatory, can take the form of a universally unique identifier 
(UUID), defined in [RFC4122], and can be bound to a network 
address of the peer, i.e., an IP address or a uniform resource 
identifier/locator (URI/URL) that uniquely identifies the 
corresponding peer in the network. The peer ID and any required 
security certificates are obtained from an offline enrollment 
server. 


peer list: A list of peers that are in the same swarm maintained by 
the tracker. A peer can fetch the peer list of a swarm from the 
tracker. 

PPSP: The abbreviation of Peer-to-Peer Streaming Protocol. 

PPSTP: The abbreviation of Peer-to-Peer Streaming Tracker Protocol. 

SEEDER: The peers in a swarm that only contribute the content they 


have to others. A SEEDER should join the swarm with complete 
media content. 


service portal: A logical entity typically used for client enrollment 
and for publishing, searching, and retrieving content information. 
It is usually located in a server of a content provider. 


swarm: A group of peers that exchange data to distribute chunks of 
the same content (e.g., video/audio program, digital file, etc.) 
at a given time. 


swarm ID: The identifier of a swarm containing a group of peers 
sharing common streaming content. The swarm ID may use a 
universally unique identifier (UUID), e.g., a 64- or 128-bit datum 
to refer to the content resource being shared among peers. 


tracker: A directory service that maintains a list of peers 
participating in a specific audio/video channel or in the 
distribution of a streaming file. It is a logical component that 
can be deployed in a centralized or distributed way. 
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transaction ID: The identifier of a request from the peer to the 
tracker. It is used to disambiguate responses that may arrive in 
a different order than the corresponding requests. 


1.2. Design Overview 


The functional entities related to peer-to-peer streaming protocols 
are the Client Media Player, the service portal, the tracker, and the 
peers. The complete description of Client Media Player and service 
portal is not discussed here, as they are not in the scope of the 
specification. The functional entities directly involved in PPSTP 
are trackers and peers (which may support different capabilities). 


The Client Media Player is a logical entity providing direct 
interface to the end user at the client device and includes the 
functions to select, request, decode, and render content. The Client 
Media Player may interface with the local peer application using the 
standard format for HTTP request and response messages [RFC7230]. 


The service portal is a logical entity typically used for client 
enrollment and for publishing, searching, and retrieving content 
information. 


A peer corresponds to a logical entity (typically in a user device) 
that actually participates in sharing media content. Peers are 
organized in various swarms; each swarm corresponds to the group of 
peers streaming certain content at any given time. 


A tracker is a logical entity that maintains the lists of peers 
storing chunks for a specific live media channel or on-demand media 
streaming content, answers queries from peers, and collects 
information on the activity of peers. While a tracker may have an 
underlying implementation consisting of more than one physical node, 
logically, the tracker can most simply be thought of as a single 
element; in this document, it will be treated as a single logical 
entity. Communication between these physical nodes to present them 
as a single tracker to peers is not considered in PPSTP, which is a 
protocol between a tracker and a peer. 


PPSTP is not used to exchange actual content data (either on demand 
or live streaming) with peers, but information about which peers can 
provide the content. PPSTP is not designed for applications for 
which in-sync reception is needed. 
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1.2.1. Typical PPSP Session 


When a peer wants to receive streaming of selected content (LEECH 
mode) : 


1. Peer connects to a tracker and joins a swarm. 
2. Peer acquires a list of other peers in the swarm from the tracker. 


3. Peer exchanges its content availability with the peers on the 
obtained peer list. 


4. Peer identifies the peers with desired content. 


5. Peer requests content from the identified peers. 


When a peer wants to share streaming content (SEEDER mode) with other 
peers: 


1. Peer connects to a tracker. 


2. Peer sends information to the tracker about the swarms it belongs 
to (joined swarms). 


3. Peer waits for other peers in LEECH mode to connect with it (see 
steps 3-5 in the previous list). 


After having been disconnected due to some termination conditions or 
user controls, a peer can resume previous activity by connecting and 
re-joining the corresponding swarm(s). 


1.2.2. Example of a PPSP Session 


In order to be able to bootstrap in the P2P network, a peer must 
first obtain a peer ID and any required security certificates or 
authorization tokens from an enrollment service (end-user 
registration). The peer ID MUST be unique (see the definition of 
"peer ID" in Section 1.1); however, the representation of the peer ID 
is not considered in this document. 
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Ho + Ho + Ho + Ho tf ERES + 
| Player | | Peer_1 | Portal | | Tracker | | Peer_2 | 
Ho + Ho + Ho + $222 TEE + 
| | | | | 
(a) |--Page request----------------- >| | 
|<-------------- Page with links--| | 
|--Select stream (MPD request) -->| | 
|<-------------------- OK+MPD (x) —- | | | 
(b) |--Start/Resume-> |--CONNECT (join x)------------ > 
EI OK== | <---------------- OK+Peerlist-- 
| | | | 
|--Get (chunk) ---> | <---------- (Peer protocol). ==========2+> >| 
|< T PS chunk--|< SS ee ee ee chunks-- | 
| | --STAT_REPORT---------------- > | | 
| ke oK--| | 
| MEE >| | 
| |<---------------- OK+Peerlist--| 
|--Get (chunk) --->|< Soe ae (Peer, Protocol). Es > | 


| <-------- chunk-- | <--------------------------------- chunks-- | 


Figure 1: A Typical PPSP Session for Streaming Content 


To join an existing P2P streaming service and to participate in 
content sharing, a peer must first locate a tracker. 


As illustrated in Figure 1, a P2P streaming session may be initiated 
starting at point (a), with the Client Media Player browsing for the 
desired content in order to request it (to the local Peer 1 in the 
figure), or resume a previously initiated stream, but starting at 
point (b). For this example, the Peer 1 is in mode LEECH. 


At point (a) in Figure 1, the Client Media Player accesses the portal 
and selects the content of interest. The portal returns the Media 
Presentation Description (MPD) file that includes information about 
the address of one or more trackers (which can be grouped by tiers of 
priority) that control the swarm x for that media content (e.g., 
content x). 


With the information from the MPD, the Client Media Player is able to 


trigger the start of the streaming session, requesting to the local 
Peer 1 the chunks of interest. 
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The PPSP streaming session is then started (or resumed) at Peer 1 by 
sending a PPSTP CONNECT message to the tracker in order to join swarm 
x. The tracker will then return the OK response message containing a 
peer list, if the CONNECT message is successfully accepted. From 
that point, every chunk request is addressed by Peer_1 to its 
neighbors (Peer_2 in Figure 1) using a peer protocol, e.g., 

[RFC7574], returning the received chunks to the Client Media Player. 


Once connected, Peer 1 needs to periodically report its status and 
statistics data to the tracker using a STAT_REPORT message. 


If Peer 1 needs to refresh its neighborhood (for example, due to 
churn), it will send a PPSTP FIND message (with the desired scope) to 
the tracker. 


Peers that are only SEEDERs (i.e., serving content to other peers), 
as are the typical cases of service provider P2P edge caches and/or 
media servers, trigger their P2P streaming sessions for content x, y, 
Dice (Figure 2), not from Media Player signals, but from some 
"Start" activation signal received from the service provider 
provisioning mechanism. In this particular case, the peer starts or 
resumes all its streaming sessions just by sending a PPSTP CONNECT 
message to the tracker (Figure 2), in order to "join" all the 
requested swarms. 


Periodically, the peer also reports its status and statistics data to 
the tracker using a PPSTP STAT_REPORT message. 


4+--------- + 4+--------- + 
| SEEDER | | Tracker | 
4+--------- + 4+--------- + 

| | 

Start->|--CONNECT (join x,y,z)-------- > | 

| <-------------------------- OK-- | 
| | 
| --STAT_REPORT----------------- > | 
| <-------------------------- Ok-- | 
--STAT_REPORT----------------- > 
| <-------------------------- Ok-- | 


Figure 2: A Typical PPSP Session for a Streaming SEEDER 
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The specification of the mechanisms used by the Client Media Player 
(or provisioning process) and the peer to signal start/resume of 
streams, request media chunks, and obtain a peer ID, security 
certificates, or tokens is not in the scope of this document. 


2. Protocol Architecture and Functional View 


PPSTP is designed with a layered approach i.e., a PPSTP 


Request/Response layer, a Message layer, and a Transport layer (see 
Figure 3). 


(HTTP) Message 


Figure 3: Abstract Layering of PPSTP 


The PPSTP Request/Response layer deals with the interactions between 
tracker and peers using request and response messages. 


The Message layer deals with the framing format for encoding and 
transmitting data through the underlying transport protocol, as well 


as the asynchronous nature of the interactions between tracker and 
peers. 


The Transport layer is responsible for the actual transmission of 
requests and responses over network transports, including the 
determination of the connection to use for a request or response 
message when using TCP or Transport Layer Security (TLS) [RFC5246] 


over it. 


2.1. Messaging Model 


The messaging model of PPSTP aligns with HTTP, which is currently in 
version 1.1 [RFC7230], and the semantics of its messages. PPSTP is 
intended to also support future versions of HTTP. 


2.2. Request/Response Model 


PPSTP uses a design like REST (Representational State Transfer) with 
the goal of leveraging current HTTP implementations and 
infrastructure, as well as familiarity with existing REST-like 
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services in popular use. PPSTP messages use the UTF-8 character set 
[RFC3629] and are either requests from peers to a tracker service or 
responses from a tracker service to peers. The request and response 
semantics are carried as entities (header and body) in messages that 
correspond to either HTTP request methods or HTTP response codes, 
respectively. 


PPSTP uses the HTTP POST method to send parameters in requests. 
PPSTP messages use JavaScript Object Notation (JSON) [RFC7159] to 
encode message bodies. 


Peers send requests to trackers. Trackers send a single response for 
each request though both requests and responses can be subject to 
fragmentation of messages in transport. 


The request messages of the base protocol are listed in Table 1: 


$o----------------------------- + 
| PPSTP Request Messages | 
$------------------------------ + 
| CONNECT | 
FIND 
STAT_REPORT 
$------------------------------ + 


Table 1: Request Messages 


CONNECT: 
This request message is used when a peer registers in the tracker 
to notify it about participation in the named swarm(s). If the 


peer is already registered in the tracker, this request message 
simply notifies the tracker about participation in the named 
swarm(s). The tracker records the peer ID, connect-time 
(referenced to the absolute time), peer IP addresses (and 
associated location information), link status, and peer mode for 
the named swarm(s). The tracker also changes the content 
availability of the valid named swarm(s), i.e., changes the peer’s 
lists of the corresponding swarm(s) for the requesting peer ID. 
On receiving a CONNECT message, the tracker first checks the peer 
mode type (SEEDER/LEECH) for the specified swarm(s) and then 
decides the next steps (see Section 4.1 for more details). 


FIND: 
This request message is used by peers to request a list of peers 
active in the named swarm from the tracker whenever needed. On 


receiving a FIND message, the tracker finds the peers listed in 
the content status of the specified swarm that can satisfy the 
requesting peer’s requirements and returns the list to the 
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requesting peer. To create the peer list, the tracker may take 

peer status, capabilities, and peer priority into consideration. 
Peer priority may be determined by network topology preference, 

operator policy preference, etc. 


STAT_REPORT: 
This request message is used to allow an active peer to send 
status (and optionally statistic data) to the tracker to signal 
continuing activity. This request message MUST be sent 
periodically to the tracker while the peer is active in the 
system. 


2.3. State Machines and Flows of the Protocol 
The state machine for the tracker is very simple, as shown in Figure 


4. Peer ID registrations represent a dynamic piece of state 
maintained by the network. 


/ \ 
| +------------ + +=========+ +======+ | 
\-| TERMINATED |<---| STARTED |<---| INIT |<-/ 
Ho + =========4 +======4 
(Transient) \- (start tracker) 
Figure 4: Tracker State Machine 


When there are no peers connected in the tracker, the state machine 
is in INIT state. 


When the first peer connects to register with its peer ID, the state 
machine moves from INIT to STARTED. As long as there is at least one 
active registration of a peer ID, the state machine remains in 
STARTED state. When the last peer ID is removed, the state machine 
transitions to TERMINATED. From there, it immediately transitions 
back to INIT state. Because of this, TERMINATED state is transient. 


Once in STARTED state, each peer is instantiated (per peer ID) in the 


tracker state machine with a dedicated transaction state machine 
(Figure 5), which is deleted when the peer ID is removed. 
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/ \ 
| +------------ + +=========+ +======+ 
\-| TERMINATED |<---| STARTED |<---| INIT |<-/ 
Ho + =========4 +======4 
(Transient) | a) X- (start tracker) 
v 
E a E TAS + HER ES + rev CONNECT 
(Transient) | TERMINATE | | START | --------------- (1) 
Ho + Ho + strt init timer 
rcv FIND (B) A | 
rcv STAT_REPORT (B) | | 
on registration error (B) | v 
on action error (A) | eS SSS SSS + 
== ==- +<--| PEER | (Transient) 
stop init timer | REGISTERED | 
snd error PEI + 


| | 
on timeout (D) | | process swarm actions 
od | e oa (2) 
stop track timer | | snd OK (PeerList) 
clean peer info | / stop init timer 
del registration / strt track timer 

or 

| | rcv FIND 
STAT REPORT ERR (C) \ | Sa l EE E (3) 
FIND ERR (C) SaaS \ / \ snd OK (PeerList) 
CONNECT ERR(C) / \ | | | | rst track timer 
rev CONNECT | (4) | | | | | 
----------- | v | {v v | rcv STAT_REPORT 
snd OK \ + + N oa ae n (3) 
rst track timer ----| TRACKING | ---- snd OK response 
snd error (C) + + rst track timer 
Figure 5: "Per-Peer-ID" State Machine and Flow Diagram 


Unlike the tracker state machine, which exists even when no peer IDs 
are registered, the "per-Peer-ID" State Machine is instantiated only 
when the peer ID starts registration in the tracker and is deleted 
when the peer ID is de-registered/removed. This allows for an 
implementation optimization whereby the tracker can destroy the 
objects associated with the "per-Peer-ID" State Machine once it 
enters the TERMINATE state (Figure 5). 


When a new peer ID is added, the corresponding "per-Peer-ID" State 
Machine is instantiated, and it moves into the PEER REGISTERED state. 
Because of that, the START state here is transient. 
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When the peer ID is no longer bound to a registration, the "per-Peer- 
ID" State Machine moves to the TERMINATE state, and the state machine 
is destroyed. 


During the lifetime of streaming activity of a peer, the instantiated 
"per-Peer-ID" State Machine progresses from one state to another in 
response to various events. The events that may potentially advance 
the state include: 


o Reception of CONNECT, FIND, and STAT_REPORT messages 
o Timeout events 


The state diagram in Figure 5 illustrates state changes, together 
with the causing events and resulting actions. Specific error 
conditions are not shown in the state diagram. 


2.3.1. Normal Operation 
For normal operation, the process consists of the following steps: 


1) When a peer wants to access the system, it needs to register with 
a tracker by sending a CONNECT message asking for the swarm(s) it 
wants to join. This request from a new peer ID triggers the 
instantiation in the tracker of a "per-Peer-ID" State Machine. In 
the START state of the new "per-Peer-ID" State Machine, the 
tracker registers the peer ID and associated information (IP 
addresses), starts the "init timer", and moves to PEER REGISTERED 
state. 


2) In PEER REGISTERED state, if the peer ID is valid, the tracker 
either: 


a) processes the requested action(s) for the valid swarm 
information contained in the CONNECT requests, and if 
successful, the tracker stops the "init timer", starts the 
"track timer", and sends the response to the peer (the response 
may contain the appropriate list of peers for the joining 
swarm(s), as detailed in Section 4.1), or 


b) moves the valid FIND request to TRACKING state. 
3) In TRACKING state, STAT_REPORT or FIND messages received from that 


peer ID will reset the "track timer", and the tracker responds to 
the requests with the following, respectively: 
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a) a successful condition, or 


b) a successful condition containing the appropriate list of peers 
for the named swarm (Section 4.2). 


4) While in TRACKING state, a CONNECT message received from that peer 
ID with valid swarm action information (Section 4.1.1) resets the 
"track timer", and the tracker responds to the request with a 
successful condition. 


.2. Error Conditions 


Peers are required not to generate protocol elements that are 


invalid. However, several situations may lead to abnormal conditions 
in the interaction with the tracker. These situations may be related 
to peer malfunction or communication errors. The tracker reacts to 


these abnormal situations depending on its current state related to a 
peer ID, as follows: 


A) In PEER REGISTERED state, when a CONNECT request only contains 
invalid swarm actions (Section 4.1.1), the tracker responds with a 
PPSTP error code as specified in Section 4.3, deletes the 
registration, and transitions to TERMINATE state for that peer ID. 
The state machine is destroyed. 


B) In PEER REGISTERED state, if the peer ID is considered invalid (in 
the case of a CONNECT request or in the case of FIND or 
STAT_REPORT requests received from an unregistered peer ID), the 
tracker responds with either a 06 (Authentication Required) 
error_code or a 03 (Forbidden Action) error_code as described in 
Section 4.3 and transitions to TERMINATE state for that peer ID. 
The state machine is destroyed. 


C) In TRACKING state (while the "track timer" has not expired), 
receiving a CONNECT message from a peer ID with invalid swarm 
actions (Section 4.1.1) or receiving a FIND/STAT_REPORT message 
from a peer ID with an invalid swarm ID is considered an error 
condition. The tracker responds with the corresponding error code 
(described in Section 4.3). 


D) In TRACKING state, without receiving messages from the peer on 
timeout (the "track timer" has expired), the tracker cleans all 
the information associated with the peer ID in all swarms it was 
joined, deletes the registration, and transitions to TERMINATE 
state for that peer ID. The state machine is destroyed. 
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NOTE: These situations may correspond to malfunctions at the peer or 
to malicious conditions. As a preventive measure, the tracker 
proceeds to TERMINATE state for that peer ID. 


3. Protocol Specification 
3.1. Presentation Language 


PPSTP uses a REST-like design, encoding the requests and responses 
using JSON [RFC7159]. For a generalization of the definition of 
protocol elements and fields, as well as their types and structures, 
this document uses a C-style notation, similar to the presentation 
language used to define TLS [RFC5246]. 


A JSON object consists of name/value pairs with the grammar specified 
in [RFC7159]. In this document, comments begin with "//", and the 
"ppsp_tp_string_t" and "ppsp_tp_integer_t" types are used to indicate 
the JSON string and number, respectively. Optional fields are 
enclosed in "[ ]" brackets. An array is indicated by two numbers in 
angle brackets, <min..max>, where "min" indicates the minimal number 
of values and "max" the maximum. An "*" is used to denote a no 
upper-bound value for "max". 


3.2. Resource Element Types 
This section details the format of PPSTP resource element types. 
3.2.1. Version 


For both requests and responses, the version of PPSTP being used MUST 
be indicated by the attribute version, defined as follows: 


ppsp_tp_integer_t ppsp_tp version t = 1 


The defined value for ppsp tp version t is listed in Table 2. 


+------------------------------ - EE EE EE EE EE EE EE EE EE EE EE EE EES + 
| ppsp_tp_version_t | Description 
$ - - - - EE EE 5 5 EE EE EE EE EE EES + 
0 Reserved 
1 PPSTP version 1 
| 2-255 | Unassigned 
4+------------------------------- EE EE EE EE EE ESE = + 


Table 2: PPSTP Version Numbers 
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3.2.2. Peer Number Element 


The peer number element is a scope selector optionally present in 
CONNECT and FIND requests. 


This element contains the attribute peer_count to indicate the 
maximum number of peers in the returned peer list. peer_count should 
be less than 30 in this specification. The other 4 attributes, i.e., 
ability_nat, concurrent_links, online_time, and upload_bandwidth may 
also be contained in this element to inform the tracker the status of 
the peer so that the tracker could return some eligible peers based 
on the implementing rules set by the service providers: 


o ability_nat is used to indicate the preferred NAT traversal 
Situation of the requesting peer. 


o concurrent_links means the number of P2P links the peer currently 
has. 


o online_time represents online duration time of the peer. The unit 
is second. 


o upload_bandwidth is the maximum upload bandwidth capability of the 
peer. The unit is Kbps. 


The scope selector element and its attributes are defined as follows: 


Object | 
ppsp_tp_integer_t peer_count; 
[ppsp_tp_string_t ability_nat = "NO_NAT" 
| "STUN" 
| "TURN"; ] 
[ppsp_tp_integer_t concurrent_links; ] 


[ppsp_tp_integer_t online_time; ] 
[ppsp_tp_integer_t upload_bandwidth; ] 
) ppsp_tp_peer_num_t; 
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3.2.3. Swarm Action Element 


The swarm action element identifies the action(s) 


May 2016 


to be taken in the 


named swarm(s) as well as the corresponding peer mode (if the peer is 
LEECH or SEEDER in that swarm). 


Object { 
ppsp_tp_string_t swarm id; //swarm ID 
ppsp. tp string t action = "JOIN" 
| "LEAVE"; // Action type of 
// the CONNECT 
// message 
ppsp_tp_string_t peer mode = "SEEDER" 


| "LEECH"; // Mode of the peer 
// participating 
// in this swarm 
) ppsp_tp_swarm_action_t; 


3.2.4. Peer Information Elements 


The peer information elements provide network identification 
information of peers. A peer information element consists of a peer 
identifier and the IP-related addressing information. 


Object { 
ppsp_tp_string_t peer_id; 
ppsp_tp_peer_addr_t peer_addr; 
) ppsp_tp peer info t; 


The ppsp_tp_peer_addr_t element includes the IP address and port, 
with a few optional attributes related to connection type and network 
location (in terms of ASN) as well as, optionally, the identifier of 
the peer protocol being used. 


Object { 


ppsp_tp_ip_address 
ppsp_tp_integer_t 
ppsp_tp_integer_t 
ppsp_tp_string_t 


[ppsp_tp_string_t 
[ppsp_tp_string_t 


[ppsp_tp_string_t 
} ppsp_tp_peer_addr_t; 
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ip_address; 
port; 
priority; 
type = "HOST" 
| "REFLEXIVE" 
| "PROXY"; 
connection = "wireless" 
| "wired"; ] 
asn; ] 
peer_protocol;] 
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The semantics of ppsp_tp_peer_addr_t attributes are listed in 


Table 3: 
+---------------------- $ O EES EER + 
| Element or Attribute | Description 
e EE A REED DT EO RE + 
| ip_address | IP address information 
| port | IP service port value 
| priority | The priority of this interface. | 
It may be determined by network 
| | topology preference, operator | 
| | policy preference, etc. How to | 
| | create a priority is outside of | 
| | the scope. The larger the value, | 
| | the higher the priority. 
type | Describes the address for NAT 

| traversal, which can be HOST 
| | REFLEXIVE or PROXY | 
| connection | Access type (wireless or wired) | 
| asn | Autonomous System Number 
| peer_protocol | Peer-to-Peer Streaming Peer | 
| | Protocol (PPSPP) supported | 
He a Se $223 SS SS a + 

Table 3: Semantics of ppsp tp peer_addr_t 

In this document, IP address is specified as ppsp tp addr value. The 


exact characters and format depend on address_type: 


o The IPv4 address is encoded as specified by the "IPv4address" rule 
in Section 3.2.2 of [RFC3986]. 


o The IPv6 address is encoded as specified in Section 4 of 
[RFC5952]. 


Object { 
ppsp_tp_string_t address_type; 
ppsp_tp_addr_value address; 

) ppsp_tp ip address; 


The peer information in responses is grouped in a 
ppsp_tp_peer_group_t element: 


Object { 
ppPsp. tp. peer info t peer_info<l..*>; 
) ppsp_tp peer. group t; 
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3.2.5. Statistics and Status Information Element 


The statistics element (stat) is used to describe several properties 
relevant to the P2P network. These properties can be related to 
stream statistics and peer status information. Each stat element 
will correspond to a property type, and several stat blocks can be 
reported in a single STAT_REPORT message, corresponding to some or 
all the swarms the peer is actively involved. This specification 
only defines the property type "STREAM STATS". 


The definition of the statistic element and attributes is as follows: 


Object { 
ppsp_tp_string_t swarm id; 
ppsp_tp_integer_t uploaded bytes; 
ppsp_tp_integer_t downloaded bytes; 
ppsp_tp_integer_t available bandwidth; 
ppsp_tp_integer_t concurrent_links; 

) stream_stats; 


The semantics of stream_stats attributes are listed in Table 4: 


HEEEEEEEEEEEEEEEEEEE EES $ EE EE EE EE EE EE EE ES + 

| Element or Attribute | Description 

$ oo $ EE EE EE EE EE + 

| swarm id | Swarm ID 

| uploaded_bytes | Bytes sent to swarm | 
downloaded_bytes Bytes received from swarm 
available_bandwidth Available instantaneous upload 

| | bandwidth | 

| concurrent_links | Number of concurrent links | 

$ o $ EE EE EE EE EE EE + 


Table 4: Semantics of stream_stats 


The stat information is grouped in the ppsp_tp_stat_group_t element: 


Object { 
ppsp_tp_string_t type = "STREAM STATS"; // property type 
stream_stats stat<l..*>; 


) ppsp_tp_stat_group_t 


Other properties may be defined, related, for example, to incentives 
and reputation mechanisms like "peer online time" or connectivity 
conditions like physical "link status", etc. 
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For that purpose, the stat element may be extended to provide 
additional specific information for new properties, elements, or 
attributes (see the guidelines in Section 7). 


3.3. Requests and Responses 
This section defines the structure of PPSTP requests and responses. 
3.3.1. Request Types 


The request type includes CONNECT, FIND, and STAT_REPORT, defined as 
follows: 


ppsp_tp_string_t ppsp_tp_request_type_t = "CONNECT" 
| "FIND" 
| "STAT REPORT"; 


3.3.2. Response Types 


Response type corresponds to the response method type of the message, 
defined as follows: 


JSONValue ppsp tp response type t = 0x00 // SUCCESSFUL 
| 0x01; // FAILED 
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3.3.3. Request Element 


The request element MUST be present in requests and corresponds to 
the request method type for the message. 


The generic definition of a request element is as follows: 


Object { 
[ppsp_tp_peer_num_t peer_num; ] 
[ppsp_tp_peer_addr_t peer_addr<1..*>;] 
ppsp_tp_swarm_action_t swarm_action<l..*>; 


) ppsp_tp_request_connect; 


Object { 
ppsp_tp_string_t swarm_id; 
[ppsp_tp peer_num_t peer_num; ] 
) ppsp_tp reguest find; 


Object { 
ppsp_tp_version_t version; 
ppsp_tp_request_type_t request_type; 
ppsp_tp_string_t transaction_id; 
ppsp_tp_string_t peer_id; 


JSONValue request_data = ppsp_tp_req_connect connect 
| ppsp_tp_req_find find 


ppsp_tp_stat_group_t stat_report; 


} ppsp_tp_request; 


A request element consists of the version of PPSTP, the request type, 
a transaction ID, the requesting peer ID, and requesting body (i.e., 
request_data). The request_data MUST be correctly set to the 
corresponding element based on the request type (see Table 5). 


4---------------------- 4+---------------------- + 
| request_type | request_data 

+---------------------- +---------------------- + 
| "CONNECT" | "connect" | 
| "FIND" | "find" | 
| "STAT_REPORT" | "stat report" | 
+---------------------- +---------------------- + 


Table 5: The Relationship between request_type and request_data 
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3.3.4. Response Element 


The generic definition of a response element is as follows: 


Object { 
ppsp_tp_version_t version; 
ppsp_tp_response_type_t response_type; 
ppsp_tp_integer_t error_code; 
ppsp_tp_string_t transaction_id; 
[ppsp_tp peer_addr_t peer_addr;] 


[ppsp_tp_swarm_action_result_t swarm_result<1..*>;] 
) ppsp_tp_response; 


A response element consists of the version of PPSTP, the response 
type, the error code, a transaction ID, and optionally the public 
address of the requesting peer and one or multiple swarm action 
result elements. Normally, swarm action result elements SHOULD be 
present and error_code MUST be set to 00 (No Error) when 
response_type is 0x00. Swarm action result elements SHOULD NOT be 
set when error_code is 01 (Bad Request). Detailed selection of 
error_code is introduced in Section 4.3. 


Object { 
ppsp_tp_string_t swarm_id; 
ppsp_tp response_type_t result; 
[ppsp_tp peer_group_t peer_group; ] 


) ppsp_tp_swarm_action_result_t; 


A swarm action result element represents the result of an action 
requested by the peer. It contains a swarm identifier that globally 
indicates the swarm, the result for the peer of this action (which 
could be CONNECT ("JOIN" or "LEAVE"), FIND, or STAT_REPORT), and 
optionally one peer group element. The attribute result indicates 
the operation result of the corresponding request. When the response 
element corresponds to the STAT_REPORT request or the result 
attribute is set to 0x01, the peer group element SHOULD NOT be set. 
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3.4. PPSTP Message Element 


PPSTP messages (requests or responses) are designed to have a similar 
structure with a root field named "PPSPTrackerProtocol" containing 
meta information and data pertaining to a request or a response. 


The base type of a PPSTP message is defined as follows: 
Object { 


JSONValue PPSPTrackerProtocol = ppsp_tp_request Request 
ppsp_tp_response Response; 


) ppsp_tp_message_root; 
4. Protocol Specification: Encoding and Operation 


PPSTP is a message-oriented request/response protocol. PPSTP 
messages use a text type encoding in JSON [RFC7159], which MUST be 
indicated in the Content-Type field in HTTP/1.1 [RFC7231], specifying 
the "application/ppsp-trackertjson" media type for all PPSTP request 
parameters and responses. 


Implementations MUST support the "https" URI scheme [RFC2818] and 
Transport Layer Security (TLS) [RFC5246]. 


For deployment scenarios where peer (client) authentication is 
desired at the tracker, HTTP Digest Access Authentication [RFC7616] 
MUST be supported, with TLS Client Authentication as the preferred 
mechanism, if available. 


PPSTP uses the HTTP POST method to send parameters in requests to 
provide information resources that are the function of one or more of 
those input parameters. Input parameters are encoded in JSON in the 
HTTP entity body of the request. 


The section describes the operation of the three types of requests of 
PPSTP and provides some examples of usage. 
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4.1. Requests and Responses 
4.1.1. CONNECT Request 


This method is used when a peer registers to the system and/or 
requests some swarm actions (join/leave). The peer MUST properly set 
the request type to CONNECT, generate and set the transaction_ids, 
set the peer_id, and include swarms the peer is interested in, 
followed by the corresponding action type and peer mode. 


o When a peer already possesses content and agrees to share it with 
others, it should set the action type to the value JOIN, as well 
as set the peer mode to SEEDER during its start (or re-start) 
period. 


o When a peer makes a request to join a swarm to consume content, it 
should set the action type to the value JOIN, as well as set the 
peer mode to LEECH during its start (or re-start) period. 


In the above cases, the peer can provide optional information on the 
addresses of its network interface(s), for example, the priority, 
type, connection, and ASN. 


When a peer plans to leave a previously joined swarm, it should set 
action type to LEAVE, regardless of the peer mode. 


When receiving a well-formed CONNECT request message, the tracker 
starts by pre-processing the peer authentication information 
(provided as authorization scheme and token in the HTTP message) to 
check whether it is valid and that it can connect to the service, 
then proceed to register the peer in the service and perform the 
swarm actions requested. If successful, a response message with a 
corresponding response value of SUCCESSFUL will be generated. 


The valid sets of the number of swarms whose action type is combined 
with peer mode for the CONNECT request logic are enumerated in 

Table 6 (referring to the "per-Peer-ID" State Machine in 

Section 2.3). 
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4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| Swarm | peer_mode | action | Initial | Final | Request | 
| Number | Value | Value | State | State | Validity 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- 
| Ï | LEECH | JOIN | START | TRACKING | Valid 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| Ï | LEECH | LEAVE | START | TERMINATE | Invalid | 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| 1 | LEECH | LEAVE | TRACKING | TERMINATE | Valid | 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| 1 | LEECH | JOIN | START | TERMINATE | Invalid | 
| į | LEECH | LEAVE | | | 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| 1 | LEECH | JOIN | TRACKING | TRACKING | Valid 

| 1 | LEECH | LEAVE | | | 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| N | SEEDER | JOIN | START | TRACKING | Valia | 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| N | SEEDER | JOIN | TRACKING | TERMINATE | Invalid | 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 
| N | SEEDER | LEAVE | TRACKING | TERMINATE | Valid | 
4+----------- 4+----------- 4+--------- 4+---------- 4+----------- 4+---------- + 


Table 6: Validity of Action Combinations in CONNECT Requests 


In the CONNECT request message, multiple swarm action elements 
ppsp_tp_swarm_action_t could be contained. Each of them contains the 
request action and the peer_mode of the peer. The peer_mode 
attribute MUST be set to the type of participation of the peer in the 
swarm (SEEDER or LEECH). 


The CONNECT message may contain multiple peer_addr elements with 
attributes ip_address, port, priority, and type (if Interactive 
Connectivity Establishment (ICE) [RFC5245] NAT traversal techniques 
are used), and optionally connection, asn, and peer_protocol 
corresponding to each of the network interfaces the peer wants to 
advertise. 


The element peer_num indicates the maximum number of peers to be 
returned in a list from the tracker. The returned peer list can be 
optionally filtered by some indicated properties, such as ability_nat 
for NAT traversal, and concurrent_links, online_time and 
upload_bandwidth for the preferred capabilities. 


The element transaction_id MUST be present in requests to uniquely 


identify the transaction. Responses to completed transactions use 
the same transaction_id as the request they correspond to. 
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The response may include peer_addr data of the requesting peer public 
IP address. Peers can use Session Traversal Utilities for NAT (STUN) 
[RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] to 
gather their candidates, in which case peer_addr SHOULD NOT present 
in the response. If no STUN is used and the tracker is able to work 
as a "STUN-like" server that can inspect the public address of a 
peer, the tracker can return the address back with a "REFLEXIVE" 
attribute type. The swarm_result may also include peer_addr data 
corresponding to the peer IDs and public IP addresses of the selected 
active peers in the requested swarm. The tracker may also include 
the attribute asn with network location information of the transport 
address, corresponding to the Autonomous System Number of the access 
network provider of the referenced peer. 


If the peer_mode is SEEDER, the tracker responds with a SUCCESSFUL 
response and enters the peer information into the corresponding swarm 
activity. If the peer_mode is LEECH (or if a SEEDER includes a 
peer_num element in the request), the tracker will search and select 
an appropriate list of peers satisfying the conditions set by the 
requesting peer. The peer list returned MUST contain the peer IDs 
and the corresponding IP addresses. To create the peer list, the 
tracker may take peer status and network location information into 
consideration to express network topology preferences or operators’ 
policy preferences with regard to the possibility of connecting with 
other IETF efforts such as Application-Layer Traffic Optimization 
(ALTO) [RFC7285]. 


IMPLEMENTATION NOTE: If no peer_num attributes are present in the 
request, the tracker may return a random sample from the peer 
population. 
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4.1.1.1. Example 


The following example of a CONNECT request corresponds to a peer that 
wants to start (or re-start) sharing its previously streamed content 
(peer_mode is SEEDER). 


POST https://tracker.example.com/video_1 HTTP/1.1 
Host: tracker.example.com 

Content-Length: 494 

Content-Type: application/ppsp-tracker+json 
Accept: application/ppsp-trackertjson 


{ 
"PPSPTrackerProtocol": { 


"version": 1, 
"request_type": "CONNECT", 
"transaction_id": "12345", 

"peer id": "656164657220", 


"connect": { 
"peer_addr": { 


"ip address": { 
"address_type": "ipv4", 
"address": W192 210 22.32" 
Vr 
"port": 80, 
"priority": 1, 
"type": "HOST", 
"connection": "wired", 
"asn": "45645" 
, 
"swarm_action": [{ 
"swarm_id": AL, 
"action": "JOIN", 
"peer_mode": "SEEDER" 
, 
{ 
"swarm_id": "2222"; 
"action": "JOIN", 
"peer_mode": "SEEDER" 


y] 


} 


Another example of the message-body of a CONNECT request corresponds 
to a peer (peer_mode is LEECH, meaning that the peer is not in 
possession of the content) requesting join to a swarm, in order to 
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start receiving the stream and providing optional information on the 
addresses of its network interface(s): 


{ 
"PPSPTrackerProtocol": { 


"version": T 
"request_type": "CONNECT", 
"transaction_id": I2 340g 
"peer_id": "656164657221", 
"connect": { 
"peer_num": { 
"peer_count": 5; 
"ability_nat": "STUN", 
"concurrent_links": UEM 
"online_time": "200", 
"upload_bandwidth": "600" 
dr 
"peer addr": [{ 
"ip address": { 
"address type": "ipv4", 
"address": "192...0:.2:5.2" 
, 
"port": 80, 
"priority": 1, 
"type": "HOST"; 
"connection": "wired", 
"asn": "3256546" 
dr 
( 
"ip address": 
"address type": "ipv6", 
"address": "2001:db8::2" 
Vr 
"port": 80, 
"priority": 2, 
"type": "HOST"; 
"connection": "wireless", 
"asn": "34563456", 
"peer_protocol": "PPSP-PP" 
Ml 
"swarm action": { 
"“swarm id": MEER 
"action": "JOIN", 
"peer mode": "LEECH" 


Standards Track 


[Page 


29] 


RFC 7846 PPSTP May 2016 


The next example of a CONNECT request corresponds to a peer leaving a 
previously joined swarm and requesting to join a new swarm. This is 
the typical example of a user watching a live channel but then 
deciding to switch to a different one: 


{ 
"PPSPTrackerProtocol": { 


"version": Lz 
"request_type": "CONNECT", 
"transaction_id": "12345"; 
"peer_id": "656164657221", 
"connect": { 
"peer_num": { 
"peer_count": D5 
"ability_nat": "STUN", 
"concurrent_links": mm, 
"online time": "200", 
"upload_bandwidth": "600" 
, 
"swarm_action": [{ 
"swarm_id": "ITELT; 
"action": "LEAVE", 
"peer_mode": "LEECH" 
, 
{ 
"swarm_id": "2222", 
"action": "JOIN", 
"peer_mode": "LEECH" 


y] 


} 


The next example illustrates the response for the previous example of 
a CONNECT request where the peer requested two swarm actions and not 

more than 5 other peers, receiving from the tracker a peer list with 

only two other peers in the swarm "2222": 


HTTP/1.1 200 OK 
Content-Length: 1342 
Content-Type: application/ppsp-tracker+json 


{ 
"PPSPTrackerProtocol": { 


"version": 1, 
"response_type": 0, 
"error code"; 0, 
"transaction_id": 1234517 
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"peer_addr": { 
"ip address": { 
"address_type": "ipv4", 


"address": 
}, 


"port": 80, 
"priority": Ly 
"asn": "64496" 
hy 
"swarm_result": { 
"swarm_id": M2222", 
"result": 0, 


"peer_group": { 
"peer_info": II 
"peer_id": 
"peer_addr": { 
"ip_address": { 


"address_type": 


"address": 
dr 
“Port: 
"priority": 
"type " : 
"connection": 
"asn": 
"peer_protocol": 


"peer_id": 
"peer_addr": { 
"ip_address": { 


"address_type": 


"address": 
, 
"port": 
"priority": 
"type " : 


"connection": 


"asn": 
"peer_protocol": 


}] 


Standards Track 
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"PPSP-PP" 


"3332001256741", 
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"198.51.100.201" 
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4.1.2. FIND Request 


This method allows peers to request a new peer list for the swarm 
from the tracker whenever needed. 


The FIND request may include a peer_number element to indicate to the 
tracker the maximum number of peers to be returned in a list 
corresponding to the indicated conditions set by the requesting peer, 
being ability_nat for NAT traversal (considering that PPSP-ICE NAT 
traversal techniques may be used), and optionally concurrent_links, 
online_time, and upload_bandwidth for the preferred capabilities. 


When receiving a well-formed FIND request, the tracker processes the 
information to check if it is valid. If successful, a response 
message with a response value of SUCCESSFUL will be generated, and 
the tracker will search out the list of peers for the swarm and 
select an appropriate peer list satisfying the conditions set by the 
requesting peer. The peer list returned MUST contain the peer IDs 
and the corresponding IP addresses. 


The tracker may take the ability of peers and popularity of the 
requested content into consideration. For example, the tracker could 
select peers with higher ability than the current peers that provide 
the content if the content is relatively popular (see Section 5.1.1); 
the tracker could also select peers with lower ability than the 
current peers that provide the content when the content is relatively 
uncommon. The tracker may take network location information into 
consideration as well, to express network topology preferences or 
operators’ policy preferences. It can implement other IETF efforts 
like ALTO [RFC7285], which is out of the scope of this document. 


The response MUST include a peer_group element that contains the peer 
IDs and the corresponding IP addresses; it may also include the 
attribute asn with network location information of the transport 
address, corresponding to the Autonomous System Number of the access 
network provider of the referenced peer. 


The response may also include a peer_addr element that includes the 
requesting peer public IP address. If no STUN is used and the 
tracker is able to work as a "STUN-like" server that can inspect the 
public address of a peer, the tracker can return the address back 
with a "REFLEXIVE" attribute type. 


IMPLEMENTATION NOTE: If no peer_num attributes are present in the 


request, the tracker may return a random sample from the peer 
population. 
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Ad sed. 


Example 


An example of the message-body of a FIND reguest, where the peer 
reguests from the tracker a list of not more than 5 peers in the 
swarm "1111" conforming to the characteristics expressed (concurrent 
links, online time, and upload bandwidth level) is as follows: 


{ 
"PPSPTrackerProtocol": { 


"version": 1, 
"request_type": "FIND", 
"transaction_id": "12345", 


"peer_id": "656164657221", 

"swarm_id": pe Ed EE 

"peer num": { 
"peer count"; Dy 
"ability_nat": "STUN", 
"concurrent_links": momy 
"online_time": 20.08" 
"upload_bandwidth": "600" 


} 


An example of the message-body of a response for the above FIND 


request, 
is as follows: 


"PPSPTrackerProtocol": { 


"version": Ty 
"response_type": 0, 
"error code": 0, 
"transaction_id": "12345", 
"swarm_result": { 
"swarm_id": "ELIIT, 
"result": o, 
“peer. group": { 
"peer info": [{ 
"peer id": "656164657221", 
"peer_addr": { 
"ip address": { 
"address_type": "ipv4", 
"address": "198.51 OO LT 
}, 
"port": 80, 
"priority": 1, 
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"type": "REFLEXIVE", 
"connection": "wireless", 
"asn": "64496" 
} 
hy 
{ 
"peer_id": "956264622298", 
"peer_addr": { 
"ip address": { 
"address_type": "ipv4", 
"address": "198.51.100.22" 
Vr 
"port": 80, 
"priority": Ll, 
"type": "REFLEXIVE", 
"connection": "wireless", 
"asn": "64496" 
} 
dr 
( 
"peer id": "3332001256741", 
"peer_addr": { 
"ip address": { 
"address_type": "ipv4", 
"address": “198.21: 100.201" 
, 
"Port": 80, 
"priority": Vy 
"type": "REFLEXIVE", 
"connection": "wireless", 
"asn": "64496" 


y] 


4.1.3. STAT REPORT Request 


This method allows peers to send status and statistic data to 
trackers. The method is periodically initiated by the peer while it 
is active. 


The peer MUST set the request_type to "STAT_REPORT", set the peer_id 


with the identifier of the peer, and generate and set the 
transaction_id. 
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The report may include multiple statistics elements describing 
several properties relevant to a specific swarm. These properties 
can be related with stream statistics and peer status information, 
including uploaded_bytes, downloaded_bytes, available_bandwidth, 
concurrent_links, etc. 


Other properties may be defined (see the guidelines in Section 7.1), 
for example, those related to incentives and reputation mechanisms. 
If no Statistics Group is included, the STAT_REPORT is used as a 
"keep-alive" message to prevent the tracker from de-registering the 
peer when the "track timer" expires. 


If the request is valid, the tracker processes the received 
information for future use and generates a response message with a 
response value of SUCCESSFUL. 


The response MUST have the same transaction_id value as the request. 
4.1.3.1. Example 
An example of the message-body of a STAT_REPORT request is: 


{ 
"PPSPTrackerProtocol": { 


"version": 1, 
"request_type": "STAT_REPORT", 
"transaction_id": "123845", 
"peer_id": "656164657221", 
"stat_report": { 
"type": "STREAM STATS", 
"Stats 4 
"swarm_id": Tas 
"uploaded_bytes": 512, 
"downloaded_bytes": 768, 
"available_bandwidth": 1024000, 
"concurrent_links": 5 
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An example of the message-body of a response for the START_REPORT 
request is: 


{ 
"PPSPTrackerProtocol": { 


"version": 1, 

"response_type": 0, 

"error code": 0, 

"transaction_id": T2345"; 

"swarm_result": { 
"swarm_id": WELLT, 
"result": 0 

} 

} 
} 
4.2. Response Element in Response Messages 


Table 7 indicates the response type and corresponding semantics. 


4-------------------- Ho + 
Response Type Semantics 
4-------------------- HEEEEEEEEEEEEEEEEEEE ES + 
| o | SUCCESSFUL | 
|1 | FAILED | 
4+-------------------- 4+--------------------- + 


Table 7: Semantics for the Value of Response Type 


SUCCESSFUL: Indicates that the request has been processed properly 
and the desired operation has completed. The body of the response 
message includes the requested information and MUST include the same 
transaction_id as the corresponding request. 


CONNECT: Returns information about the successful registration of 
the peer and/or of each swarm action requested. May additionally 
return the list of peers corresponding to the action attribute 
requested. 


FIND: Returns the list of peers corresponding to the requested 
scope. 


STAT_REPORT: Confirms the success of the requested operation. 


FAILED: Indicates that the request has not been processed properly. 
A corresponding error_code SHOULD be set according to the conditions 
described in Section 4.3. 
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AO 


Error and Recovery Conditions 


If the peer receives an invalid response, the same request with 
identical content including the same transaction_id MUST be repeated. 


The transaction_id on a request can be reused if and only if all of 
the content is identical, including date/time information. Details 
of the retry process (including time intervals to pause, number of 
retries to attempt, and timeouts for retrying) are implementation 
dependent. 


The tracker MUST be prepared to receive a request with a repeated 
transaction_id. 


Error situations resulting from normal operation or from abnormal 
conditions (Section 2.3.2) MUST be responded to with response_type 
set to 0x01 and with the adequate error_code, as described here: 


o 


CFUZ; 


If the message is found to be incorrectly formed, the receiver 
MUST respond with a 01 (Bad Request) error_code with an empty 
message-body (no peer_addr and swarm_result attributes). 


If the version number of the protocol is for a version the 
receiver does not support, the receiver MUST respond with a 02 
(Unsupported Version Number) error_code with an empty message-body 
(no peer_addr and swarm_result attributes). 


In the PEER REGISTERED and TRACKING states of the tracker, certain 
requests are not allowed (Section 2.3.2). The tracker MUST 
respond with a 03 (Forbidden Action) error_code with an empty 
message-body (no peer_addr and swarm_result attributes). 


If the tracker is unable to process a request message due to an 
unexpected condition, it SHOULD respond with a 04 (Internal Server 
Error) error_code with an empty message-body (no peer_addr and 
swarm_result attributes). 


If the tracker is unable to process a request message because it 
is in an overloaded state, it SHOULD respond with a 05 (Service 

Unavailable) error_code with an empty message-body (no peer_addr 
and swarm_result attributes). 


If authentication is required for the peer to make the request, 
the tracker SHOULD respond with a 06 (Authentication Required) 
error_code with an empty message-body (no peer_addr and 
swarm_result attributes). 
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4.4. Parsing of Unknown Fields in message-body 


This document only details object members used by this specification. 
Extensions may include additional members within JSON objects defined 
in this document. PPSTP implementations MUST ignore unknown members 

when processing PPSTP messages. 


5. Operations and Manageability 


This section provides the operational and management aspects that are 
required to be considered in implementations of PPSTP. These aspects 
follow the recommendations expressed in [RFC5706]. 


5.1. Operational Considerations 


PPSTP provides communication between trackers and peers and is 
conceived as a "client-server" mechanism, allowing the exchange of 
information about the participant peers sharing multimedia streaming 
content. 


The "server" component, i.e., the tracker, is a logical entity that 
can be envisioned as a centralized service (implemented in one or 
more physical nodes) or a fully distributed service. 


The "client" component can be implemented at each peer participating 
in the streaming of content. 


5.1.1. Installation and Initial Setup 


Content providers wishing to use PPSP for content distribution should 
set up at least a PPSP tracker and a service portal (public web 
server) to publish links of the content descriptions, for access to 
their on-demand or live original content sources. Content and 
service providers should also create conditions to generate peer IDs 
and any required security certificates, as well as chunk IDs and 
swarm IDs for each streaming content. The configuration processes 
for the PPSP tracking facility, the service portal, and content 
sources are not standardized, enabling flexibility for implementers. 


The swarm IDs of available content, as well as the addresses of the 
PPSP tracking facility, can be distributed to end users in various 
ways, but it is common practice to include both the swarm ID and the 
corresponding PPSP tracker addresses (as URLS) in the MPD of the 
content, which is obtainable (a link) from the service portal. 


The available content could have different importance attribute 
values to indicate whether the content is popular or not. However, 
it is a totally implementation design and outside the scope of this 
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specification. For example, the importance attribute values of the 
content could be set by content providers when distributing them or 
could be determined by the tracker based on the statistics of the 
requests from the peers that request the content. The tracker could 
set an upper threshold to decide that the content is popular enough 
when the importance attribute value is higher than the upper 
threshold. The tracker could also set a lower threshold to decide 
that the content is uncommon enough when the importance attribute 
value is lower than the lower threshold. 


End users browse and search for desired content in the service portal 
and select by clicking the links of the corresponding MPDs. This 
action typically requires security certificates or authorization 
tokens from an enrollment service (end-user registration) and then 
launches the Client Media Player (with PPSP awareness), which will 
then, using PPSTP, contact the PPSP tracker to join the corresponding 
swarm and obtain the transport addresses of other PPSP peers in order 
to start streaming the content. 


5.1.2. Migration Path 


There is no previous standard protocol providing functionality 
similar to PPSTP. However, some popular proprietary protocols, e.g., 
BitTorrent, are used in existing systems. There is no way for PPSTP 
to migrate to proprietary protocols like the BitTorrent tracker 
protocol. Because PPSTP is an application-level protocol, there is 
no harm in PPSTP having no migration path. However, proprietary 
protocols migrating to standard protocols like PPSTP can solve the 
problems raised in [RFC6972]. It is also possible for systems to use 
PPSTP as the management protocol to work with exiting propriety peer 
protocols like the BitTorrent peer protocol. 


5.1.3. Requirements on Other Protocols and Functional Components 
For security reasons, when using the Peer-to-Peer Streaming Peer 
Protocol (PPSPP) with PPSTP, the mechanisms described in Section 6.1 
should be observed. 

5.1.4. Impact on Network Operation 
As the messaging model of PPSTP aligns with HTTP and the semantics of 


its messages, the impact on network operation is similar to using 
HTTP. 
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5.1.5. Verifying Correct Operation 


The correct operation of PPSTP can be verified both at the tracker 
and at the peer by logging the behavior of PPSTP. Additionally, the 
PPSP tracker collects the status of the peers, including the peers’ 
activity; such information can be used to monitor and obtain the 
global view of the operation. 


5.2. Management Considerations 


The management considerations for PPSTP are similar to other 
solutions using HTTP for large-scale content distribution. The PPSP 
tracker can be realized by geographically distributed tracker nodes 
or multiple server nodes in a data center. As these nodes are akin 
to WWW nodes, their configuration procedures, detection of faults, 
measurement of performance, usage accounting, and security measures 
can be achieved by standard solutions and facilities. 


5.2.1. Interoperability 


Interoperability refers to allowing information sharing and 
operations between multiple devices and multiple management 
applications. For PPSTP, distinct types of devices host PPSTP 
trackers and peers. Therefore, support for multiple standard schema 
languages, management protocols, and information models, suited to 
different purposes, was considered in the PPSTP design. 
Specifically, management functionality for PPSTP devices can be 
achieved with the Simple Network Management Protocol (SNMP) 
[RFC3410], syslog [RFC5424], and the Network Configuration Protocol 
(NETCONF) [RFC6241]. 


5.2.2. Management Information 


PPSP trackers may implement SNMP management interfaces, namely, the 
Application Management MIB [RFC2564], without the need to instrument 
the tracker application itself. The channel, connections, and 
transaction objects of the Application Management MIB can be used to 
report the basic behavior of the PPSP tracker service. 


The Application Performance Measurement MIB (APM-MIB) [RFC3729] and 
the Transport Performance Metrics MIB (TPM-MIB) [RFC4150] can be used 
with PPSTP to provide adequate metrics for the analysis of 
performance for transaction flows in the network, in direct 
relationship to the transport of PPSTP. 


The Host Resources MIB [RFC2790] can be used to supply information on 


the hardware, the operating system, and the installed and running 
software on a PPSP tracker host. 
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The TCP-MIB [RFC4022] can additionally be considered for network 
monitoring. 


Logging is an important functionality for PPSTP trackers and peers; 
it is done via syslog [RFC5424]. 


5.2.3. Fault Management 


As PPSP tracker failures can be mainly attributed to host or network 
conditions, the facilities previously described for verifying the 
correct operation of PPSTP and the management of PPSP tracker servers 
appear sufficient for PPSTP fault monitoring. 


5.2.4. Configuration Management 


PPSP tracker deployments, when realized by geographically distributed 
tracker nodes or multiple server nodes in a data center, may benefit 
from a standard way of replicating atomic configuration updates over 
a set of server nodes. This functionality can be provided via 
NETCONF [RFC6241]. 


5.2.5. Accounting Management 


PPSTP implementations, primarily in content provider environments, 
can benefit from accounting standardization efforts as described in 
[RFC2975], which indicates that accounting management is "concerned 
with the collection of resource consumption data for the purposes of 
capacity and trend analysis, cost allocation, auditing, and billing". 


5.2.6. Performance Management 


Because PPSTP is transaction oriented, its performance in terms of 
availability and responsiveness can be measured with the facilities 
of the APM-MIB [RFC3729] and the TPM-MIB [RFC4150]. 


5.2.7. Security Management 


Standard SNMP notifications for PPSP tracker management [RFC5590] and 
syslog messages [RFC5424] can be used to alert operators to the 
conditions identified in the security considerations (Section 6). 


The statistics collected about the operation of PPSTP can be used for 
detecting attacks (e.g., the receipt of malformed messages, messages 
out of order, or messages with invalid timestamps). However, 
collecting such endpoint properties may also raise some security 
issues. For example, the statistics collected by the tracker may be 
disclosed to an unauthorized third party that has malicious 
intentions. To address such risk, the provider of the tracker should 
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evaluate how much information is revealed and the associated risks. 
A confidentiality mechanism must be provided by HTTP over TLS to 
guarantee the confidentiality of PPSTP. 


6. Security Considerations 


P2P streaming systems are subject to attacks by malicious or 
unfriendly peers/trackers that may eavesdrop on signaling, forge/deny 
information/knowledge about streaming content and/or its 
availability, impersonate a valid participant, or launch DoS attacks 
on a chosen victim. 


No security system can guarantee complete security in an open P2P 
streaming system where participants may be malicious or 
uncooperative. The goal of the security considerations described 
here is to provide sufficient protection for maintaining some 
security properties during tracker-peer communication even in the 
face of a large number of malicious peers and/or eventual distrustful 
trackers (under the distributed tracker deployment scenario). 


Since the protocol uses HTTP to transfer signaling, most of the 
security considerations described in [RFC7230] and [RFC7231] also 
apply. Due to the transactional nature of the communication between 
peers and tracker, the method for adding authentication and data 
security services can be the OAuth 2.0 Authorization [RFC6749] with a 
bearer token, which provides the peer with the information required 
to successfully utilize an access token to make protected requests to 
the tracker. 


6.1. Authentication between Tracker and Peers 


To protect PPSTP signaling from attackers pretending to be valid 
peers (or peers other than themselves), all messages received in the 
tracker SHOULD be received from authorized peers. For that purpose, 
a peer SHOULD enroll in the system via a centralized enrollment 
server. The enrollment server is expected to provide a proper peer 
ID for the peer and information about the authentication mechanisms. 
The specification of the enrollment method and the provision of 
identifiers and authentication tokens is out of the scope of this 
specification. 


Transport Layer Security (TLS) [RFC5246] MUST be used in the 
communication between peers and tracker to provide privacy and data 
integrity. Software engineers developing and service providers 
deploying the tracker should make themselves familiar with the Best 
Current Practices (BCP) on configuring HTTP over TLS [RFC7525]. 
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OAuth 2.0 Authorization [RFC6749] SHOULD also be considered when 
digest authentication [RFC7616] and HTTPS client certificates are 
required. 


6.2. Content Integrity Protection against Polluting Peers/Trackers 


Malicious peers may claim ownership of popular content to the tracker 
and try to serve polluted (i.e., decoy content or even virus/trojan- 
infected content) to other peers. Since trackers do not exchange 
content information among peers, it is difficult to detect whether or 
not a peer is polluting the content. Usually, this kind of pollution 
can be detected by the Peer-to-Peer Streaming Peer Protocol (PPSPP) 
[RFC7574] with requiring the use of Merkle Hash Tree scheme for 
protecting the integrity of the content. More details can be seen in 
Section 5 of [RFC7574]. 


Some attackers that disrupt P2P streaming on behalf of content 
providers may provide false or modified content or peer list 
information to achieve certain malicious goals. Peers connecting to 
those portals or trackers provided by the attackers may be redirected 
to some corrupted malicious content. However, there is no standard 
way for peers to avoid this kind of situation completely. Peers can 
have mechanisms to detect undesirable content or results themselves. 
For example, if a peer finds that the portal returned some undesired 
content information or the tracker returned some malicious peer 
lists, the peer may choose to quit the swarm or switch to other P2P 
streaming services provided by other content providers. 


6.3. Residual Attacks and Mitigation 


To mitigate the impact of Sybil attackers impersonating a large 
number of valid participants by repeatedly acquiring different peer 
identities, the enrollment server SHOULD carefully regulate the rate 
of peer/tracker admission. 


There is no guarantee that peers honestly report their status to the 
tracker, or serve authentic content to other peers as they claim to 
the tracker. It is expected that a global trust mechanism, where the 
credit of each peer is accumulated from evaluations for previous 
transactions, may be taken into account by other peers when selecting 
partners for future transactions, helping to mitigate the impact of 
such malicious behaviors. A globally trusted tracker may also take 
part in the trust mechanism by collecting evaluations, computing 
credit values, and providing them to joining peers. 


Cruz, et al. Standards Track [Page 43] 


REC 7846 PPSTP May 2016 


6.4. Pro-incentive Parameter Trustfulness 


Property types for STAT_REPORT messages may consider additional pro- 
incentive parameters (see the guidelines for extension in Section 7), 
which can enable the tracker to improve the performance of the whole 
P2P streaming system. Trustworthiness of these pro-incentive 
parameters is critical to the effectiveness of the incentive 
mechanisms. Furthermore, the amount of both uploaded and downloaded 
data should be reported to the tracker to allow checking for 
inconsistencies between the upload and download report and to 
establish an appropriate credit/trust system. 


One such solution could be a reputation-incentive mechanism, based on 
the notions of reputation, social awareness, and fairness. The 
mechanism would promote cooperation among participants (via each 
peer’s reputation) based on the history of past transactions, such 
as, count of chunk requests (sent and received) in a swarm, 
contribution time of the peer, cumulative uploaded and downloaded 
content, JOIN and LEAVE timestamps, attainable rate, etc. 


Alternatively, exchange of cryptographic receipts signed by receiving 
peers can be used to attest to the upload contribution of a peer to 
the swarm, as suggested in [Contracts]. 


6.5 Privacy for Peers 


PPSTP provides mechanisms in which the peers can send messages 
containing IP addresses, ports, and other information to the tracker. 
A tracker or a third party who is able to intercept such messages can 
store and process the obtained information in order to analyze peers’ 
behaviors and communication patterns. Such analysis can lead to 
privacy risks. For example, an unauthorized party may snoop on the 
data transmission from the peer to a tracker in order to introduce 
some corrupted chunks. 


The Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574] has 
already introduced some mechanisms to protect streamed content; see 


Sections 12.3 and 12.4 of [RFC7574]. For PPSTP, peer implementations 
as well as tracker implementations MUST support the "https" URI 
scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. In 


addition, a peer should be cognizant about potential trackers 
tracking through queries of peers, e.g., by using HTTP cookies. 
PPSTP as specified in this document does not rely on HTTP cookies. 
Thus, peers may decide not to return cookies received from the 
tracker, in order to make additional tracking more difficult. 
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7. 


7. 


Guidelines for Extending PPSTP 


Extension mechanisms allow designers to add new features or to 
customize existing features of a protocol for different operating 
environments [RFC6709]. 


Extending a protocol implies either the addition of features without 
changing the protocol itself or the addition of new elements creating 
new versions of an existing schema and therefore new versions of the 
protocol. 


In PPSTP, this means that an extension MUST NOT alter an existing 
protocol schema as the changes would result in a new version of an 
existing schema, not an extension of an existing schema, typically 
non-backwards-compatible. 


Additionally, a designer MUST remember that extensions themselves may 
also be extensible. 


Extensions MUST adhere to the principles described in this section in 
order to be considered valid. 


Extensions MUST be documented in Standards Track RFCs if there are 
requirements for coordination, interoperability, and broad 
distribution. 


1. Forms of PPSTP Extension 


In PPSTP, two extension mechanisms can be used: a Request-Response 
Extension or a Protocol-Level Extension. 


o Reguest-Response Extension: Adding elements or attributes to an 
existing element mapping in the schema is the simplest form of 
extension. This form should be explored before any other. This 
task can be accomplished by extending an existing element mapping. 


For example, an element mapping for the Statistics Group can be 
extended to include additional elements needed to express status 
information about the activity of the peer, such as online time 
for the stat element. 


o Protocol-Level Extension: If there is no existing element mapping 
that can be extended to meet the requirements and the existing 
PPSTP request and response message structures are insufficient, 
then extending the protocol should be considered in order to 
define new operational requests and responses. 
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For example, to enhance the level of control and the granularity 
of the operations, a new version of the protocol with new messages 
(JOIN, DISCONNECT), a retro-compatible change in semantics of an 
existing CONNECT request/response, and an extension in STAT_REPORT 
could be considered. 


As illustrated in Figure 6, the peer would use an enhanced CONNECT 
request to perform the initial registration in the system. Then 
it would join a first swarm as SEEDER, later join a second swarm 
as LEECH, and then disconnect from the latter swarm but remain as 
SEEDER for the first one. When deciding to leave the system, the 
peer disconnects gracefully from it: 


+-------- + 4+--------- + 
| Peer | | Tracker | 
+-------- + 4+--------- + 

| | 

| --CONNECT--------------------- > | 

<-------------------------- OK-- | 

| -- JOIN (swarm_a; SEEDER) ---------- > | 

| <-------------------------- OK-- | 

| --STAT_REPORT (activity) ------- > | 

| <-------------------------- Ok-- | 

| --JOIN (swarm_b; LEECH) --------- > | 

| <----------------- OK+PeerList--| 

| --STAT_REPORT (ChunkMap_b) ----- >| 

| <-------------------------- Ok-- | 

| --DISCONNECT (swarm_b) --------- > | 

| <-------------------------- Ok-- | 

| --STAT_REPORT (activity) ------- > | 

| <-------------------------- Ok-- | 

| --DISCONNECT Lo > | 

| <--------------------- Ok (BYE) -- | 


Figure 6: Example of a Session for a PPSTP Extended Version 
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Issues to Be Addressed in PPSTP Extensions 


There are several issues that all extensions should take into 
consideration. 


o 


Cruz; 


Overview of the Extension: It is RECOMMENDED that extensions to 
PPSTP have a protocol overview section that discusses the basic 
operation of the extension. The most important processing rules 
for the elements in the message flows SHOULD also be mentioned. 


Backward Compatibility: The new extension MUST be backward 
compatible with the base PPSTP specified in this document. 


Syntactic Issues: Extensions that define new request/response 
methods SHOULD use all capitals for the method name, keeping with 
a long-standing convention in many protocols, such as HTTP. 
Method names are case sensitive in PPSTP. Method names SHOULD be 
shorter than 16 characters and SHOULD attempt to convey the 
general meaning of the request or response. 


Semantic Issues: PPSTP extensions MUST clearly define the 
semantics of the extensions. Specifically, the extension MUST 
specify the behaviors expected from both the peer and the tracker 
in processing the extension, with the processing rules in temporal 
order of the common messaging scenario. 


Processing rules generally specify actions to be taken on receipt 
of messages and expiration of timers. 


The extension SHOULD specify procedures to be taken in exceptional 
conditions that are recoverable. Handling of unrecoverable errors 
does not require specification. 


Security Issues: As security is an important component of any 
protocol, designers of PPSTP extensions need to carefully consider 
security requirements, e.g., authorization requirements and 
requirements for end-to-end integrity. 


Examples of Usage: The specification of the extension SHOULD give 
examples of message flows and message formatting and include 
examples of messages containing new syntax. Examples of message 
flows should be given to cover common cases and at least one 
failure or unusual case. 
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Ta 


IANA Considerations 


MIME Type Registry 


May 2016 


This document registers "application/ppsp-tracker+json" media types. 


Type name: application 
Subtype name: ppsp-trackertjson 
Required parameters: n/a 


Optional parameters: n/a 


Encoding considerations: Encoding considerations are identical to 


those specified for the "application/json" media type. See 


[RFC7159]. 


Security considerations: See Section 6 of RFC 7846. 


Interoperability considerations: This document specifies the format 


of conforming messages and the interpretation thereof. 


Published specification: RFC 7846. 


Applications that use this media type: PPSP trackers and peers 
either stand alone or are embedded within other applications. 


Additional information: 
Magic number(s): n/a 
File extension(s): n/a 
Macintosh file type code(s): n/a 


Fragment identifier considerations: n/a 


Person & email address to contact for further information: 


Authors’ Addresses section. 

Intended usage: COMMON 

Restrictions on usage: none 

Author: See Authors’ Addresses section of RFC 7846. 


Change controller: IESG (iesg@ietf.org) 
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8.2. PPSTP Version Number Registry 


IANA has created the "PPSTP Version Number Registry". Values are 
integers in the range 0-255, with initial assignments and 
reservations given in Table 2. New PPSTP version types are assigned 
after IETF Review [RFC5226] to ensure that proper documentation 
regarding the new version types and their usage has been provided. 


8.3. PPSTP Request Type Registry 


IANA has created the "PPSTP Request Type Registry". Values are 
strings listed in Table 8. New PPSTP request types are assigned 
after IETF Review [RFC5226] to ensure that proper documentation 
regarding the new request types and their usage has been provided. 


Pos pe o OO EE SS SO SS SS OO BEES + 

| request_type | Description 

$ O EE de EE EE ELE EE EE + 

| "CONNECT" | Returns information about the successful | 

| | registration of the peer and/or of each | 

| | swarm action requested. May additionally | 

| | return the list of peers corresponding to 
the action attribute 

| | requested. | 

| "FIND" | Returns the list of peers corresponding | 

| | to the requested scope. 

| "STAT_REPORT" | Confirms the success of the requested 

| | operation. | 

4+---------------------- $------- 5-5-5 5-5-5 = + 


Table 8: The PPSTP Request Type Registry 
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8.4. 


IANA has created the "PPSTP Error Code Registry". 
strings listed in Table 9. 


PPSTP 


PPSTP Error Code Registry 


May 2016 


Values are the 


New PPSTP error codes are assigned after 


IETF Review [RFC5226] to ensure that proper documentation regarding 
the new error codes and their usage has been provided. 


Cruz; 


+ a es aa al a ke Need a A 
| error_code 


————— + — + 


+ 


Description 


No Error 

Bad Request 

Unsupported Version Number 
Forbidden Action 

Internal Server Error 
Service Unavailable 
Authentication Required 


Table 9: The PPSTP Error Code Registry 
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